Aplicación del modelo de madurez de capacidad (CMM) en la empresa BNYCS (página 2)

– Planificación. La
simulación del proceso software se puede aplicar tanto en
la planificación inicial del proyecto como en las
sucesivas planificaciones o modificaciones que se realicen
conforme el proyecto progresa. La predicción del
esfuerzo/coste, el tiempo de desarrollo, la calidad del producto,
los niveles de personal necesarios, etc. son algunas de las
posibilidades que se pueden estudiar mediante la
simulación de diferentes escenarios. – Control y
gestión operacional. La simulación también
puede proporcionar un soporte efectivo para las actividades de
control y gestión operacional de los proyectos software.
Por ejemplo, la evolución de las variables claves del
proyecto (como el estado actual del progreso, el consumo de
recursos, la calidad percibida, etc.) puede ser monitorizada y
comparada con los valores planificados. Los directores de
proyectos también pueden utilizar la simulación
para facilitar la toma de decisiones operacionales como, por
ejemplo, si es conveniente comenzar una determinada actividad en
el momento actual o interesa retrasar dicho comienzo. La
simulación también puede favorecer el estudio de
las consecuencias de un cambio en las prioridades del proyecto,
en las necesidades de contratación o en la
planificación inicial. En los casos en los que la
simulación se utilice para la monitorización y
control operacional resultará del todo imprescindible
disponer de información detallada, actualizada y precisa
del proyecto cuyo modelo se simula. – Mejora del proceso y cambio
tecnológico. La simulación puede facilitar el
proceso de toma de decisiones en el ámbito de la mejora
del proceso ya que permite predecir el impacto potencial de un
cambio en el proceso antes de que éste se haga efectivo en
la práctica. Como consecuencia, también será
posible utilizar la simulación en el diseño de
procesos estándares específicos para una
determinada organización. En este mismo sentido, la
simulación también puede facilitar la toma de
decisiones relacionadas con un cambio de la tecnología
empleada dentro de la organización. – Comprensión.
El propio proceso de construcción de un modelo de
simulación permite ampliar el conocimiento que se tiene
acerca de la organización y de sus procesos de desarrollo,
ya que resulta necesario conocer y comprender correctamente los
lazos de realimentación, sus efectos y los retrasos
existentes en el proceso, entre otros aspectos, para que el
modelo sea preciso. Además, en esta etapa de
construcción del modelo es probable que se identifiquen de
manera manifiesta aquellas áreas del proceso donde la
incertidumbre es mayor y resulte más complicado, al igual
que en la realidad, predecir la salida. Finalmente, los modelos
de simulación favorecen la comunicación entre los
miembros de la organización ya que permiten compartir,
bajo una representación formalizada, el conocimiento que
cada miembro tenga del proceso software. – Formación y
aprendizaje. No es una novedad que la simulación se defina
como una herramienta eficaz para la formación y el
aprendizaje. La simulación es un medio para que el
personal pueda practicar o aprender gestión de proyectos.
Un entorno de entrenamiento basado en simulación permite
aprender los resultados más probables de las decisiones de
gestión más frecuentes y que, a menudo, resultan
incorrectas como, por ejemplo, adelantar excesivamente la etapa
de codificación, eliminar las revisiones o reducir el
esfuerzo asignado a las actividades de prueba. El entrenamiento
basado en la simulación también ayuda a los
directores de proyectos a aceptar resultados muy diferentes a los
que esperaban cuando tomaron la decisión. De esta manera,
se consigue que el director obtenga una experiencia que, de otra
forma, sólo hubiera adquirido tras años de
experiencia gestionando proyectos reales.

2 Justificación

Aunque los métodos tradicionales
para la gestión de proyectos software hayan revelado en
las últimas décadas sus carencias no dejan por ello
de ser herramientas necesarias.

Una vez analizadas las
características y ventajas de los modelos de
simulación sería importante tratar de integrar
ambos conjuntos de técnicas en un único marco que
reúna las ventajas de ambos enfoques y que se convierta en
un herramienta efectiva en el diseño de mejoras del
proceso y en la evaluación de sus resultados sin coste o
riesgo.

En [5] se muestran las conclusiones obtenidas tras
comparar ambos enfoques para la gestión de proyectos y
señala también la necesidad de integrar ambas
técnicas. Los enfoques tradicional y dinámico
persiguen objetivos similares, tales como la estimación de
la duración del proyecto o de su coste, pero la
perspectiva desde la que trabajan es distinta. La mayoría
de las técnicas tradicionales se basa en una
descomposición descendente del proyecto en busca
de sus componentes fundamentales, centrándose en detallar
esta estructura, y estimar los costes, plazos y recursos
necesarios. El enfoque de los sistemas dinámicos es
diferente. Las técnicas de gestión basadas en
modelos dinámicos se caracterizan por su enfoque
ascendente que trata de agregar las
características de un proyecto en un único modelo o
sistema cuya evolución está regida por relaciones
internas de tipo causal.

De las características anteriormente expuestas
puede deducirse que los modelos dinámicos están
indicados especialmente para tratar problemas situados en el
nivel estratégico de los proyectos, mientras que los
métodos tradicionales resultan útiles en el nivel
operacional.

Con el desarrollo de un marco dinámico integrado
para la mejora de los procesos software (DIFSPI, Dynamic
Integrated Framework for Software Process Improvement),
pretendemos ofrecer una metodología y un entorno de
trabajo que combine las ventajas de ambos conjuntos de
técnicas y que permita, tanto a los directores de
proyectos como a los miembros del grupo de mejora de la
organización (SEIG, Software Engineering Improvement
Group), diseñar y evaluar nuevas mejoras del proceso
software.

Uno de los objetivos principales de DIFSPI consiste en
facilitar la evolución del nivel de madurez de las
organizaciones de desarrollo de acuerdo con el modelo CMM [3]. El
propio diseño y construcción del marco y de los
modelos dinámicos que lo integran permite, en sí
mismo, la definición de métricas que, por un lado
son necesarias para la inicialización y validación
del modelo y que, por otro lado, sirven para la definición
de un programa de recogidas de métricas concretas
dentro de la organización. Esta recogida definida y
sistemática de métricas no sólo es
útil para la utilización de modelos
dinámicos sino que también se revela como una
oportunidad única para el conocimiento real del estado de
los procesos dentro de la organización. Conocimiento que,
sin duda, es indispensable tener, antes de abordar actividades de
mejora.

3 Desarrollo del DIFSPI

3.1 Aproximación conceptual

La utilización de la simulación para la
mejora de procesos dentro del modelo CMM no es una idea nueva. De
hecho [2] ya propone al modelo CMM como un marco incremental
excelente para la obtención de experiencia a través
de la simulación de proyectos.

No obstante, no consta en la literatura la
construcción sistemática de un marco que favorezca,
a la vez que es construido o implementado en un
organización, la evolución de su nivel de madurez,
sin renunciar a las ventajas que la simulación del proceso
de desarrollo ya posee por sí misma y que fueron
señaladas en el primer apartado.

Una de las características definitorias del
empleo de modelos dinámicos en cualquier área de la
ingeniería es que sea cual fuere el modelo, éste
requiere satisfacer un determinado nivel de calidad o fiabilidad
antes de poder ser utilizado en la práctica. De hecho, la
potencia y versatilidad de los sistemas de simulación
actuales facilitan en gran medida la construcción de
modelos dinámicos que pueden llegar a ser realmente
complejos. Sin embargo, si la organización no dispone de
la suficiente información para inicializar y definir los
parámetros y funciones que gobiernan la evolución
del comportamiento del modelo, éste resultará
inútil. El problema mencionado es uno de los
inconvenientes más frecuentes con el que podemos
encontrarnos cuando se intentan aplicar modelos clásicos
de simulación, como el desarrollado por [1], en
organizaciones situadas en niveles bajos de madurez, sobre todo
en las etapas iniciales de los proyectos [6].

Por tanto, resulta posible afirmar que el beneficio
obtenido con la aplicación de modelos dinámicos
dentro de la organización está directamente
relacionado con el conocimiento y la información
empírica que la misma tenga de sus procesos y cómo
valide sus procesos simulados. Queda pues, de manifiesto, que el
nivel de madurez de la organización guarda una
relación directa con la facilidad de validar los modelos
dinámicos y, por tanto, con su fiabilidad.

La figura 1 muestra las relaciones existentes entre el
nivel de madurez de una organización, la
utilización de modelos dinámicos y las ventajas
derivadas. El ciclo de realimentación positivo viene a
ilustrar un conjunto de relaciones causales que refuerzan la
recogida de métricas en la organización para su
utilización en el modelo dinámico. Si nos situamos
en una organización correspondiente a un nivel de madurez
1 según el modelo CMM, la ausencia de métricas y de
información relativa a unos procesos que están
aún por definir será la característica
predominante. Por ello, para utilizar un modelo dinámico
en estos niveles será necesario definir, en primer lugar,
los procesos generales de los proyectos software y las
métricas requeridas para estos procesos. Surge en este
momento la incertidumbre de qué datos recolectar, con
qué frecuencia y precisión. El proceso de
diseño del modelo dinámico aporta una gran ayuda en
este momento. Para construir un modelo se requiere conocer, en
primer lugar qué es lo que se desea modelar, delimitar su
ámbito y definir qué comportamientos se desean
investigar.

Estos comportamientos, que constituyen el objetivo del
modelo, vienen regidos por la evolución, dada bajo la
forma de relaciones causales, del modelo a partir de unas
condiciones iniciales. Son precisamente estas condiciones
iniciales junto con aquellas que rigen la evolución del
comportamiento, las que resuelven la cuestión de
qué datos recoger, con qué frecuencia y
precisión. Aquellos datos necesarios para inicializar el
modelo y para definir las leyes de su comportamiento
dinámico serán los componentes principales del
programa de recogida de métricas.

Tras la definición de los componentes del sistema
de métricas, éste puede implementarse en la
organización, traduciéndose en la definición
y desarrollo de una base de datos histórica. Estos datos
de carácter histórico serán los que se
utilizarán para la simulación y validación
empírica del modelo construido. Una vez demostrada la
validez de dicho modelo, los valores ofrecidos por la
simulación permiten instanciar una base de datos que
permita realizar análisis acerca de los efectos de
diferentes acciones o mejoras.

Un aumento de la complejidad de las acciones que se
pretenden evaluar, se traduce en un aumento de la complejidad del
modelo dinámico que vuelve a diseñar un nuevo
programa de recogida de métricas para los nuevos
módulos de simulación, cerrándose, con ello,
el ciclo.

La mitad inferior de la figura 1 viene a mostrar de
manera gráfica los efectos derivados de la
utilización de modelos dinámicos en el
ámbito de la mejora de procesos. La utilización de
modelos dinámicos diseñados y calibrados de acuerdo
con los datos de la organización presenta tres ventajas
importantes. En primer lugar, los datos resultantes de la
simulación de un modelo dinámico pueden utilizarse
en la realización de predicciones sobre la
evolución del proyecto. Si el nivel de madurez de la
organización es bajo, estos datos permiten la
observación de las tendencias gráficas que muestran
la evolución del proyecto a partir de determinadas
condiciones iniciales (establecidas por los valores de los
parámetros de inicialización); cuando el nivel de
madurez aumenta, la definición y conocimiento de los
procesos de desarrollo también, por lo que los resultados
de la simulación se convierten en estimaciones
cuantitativas reales que predicen, de acuerdo con la
incertidumbre de sus parámetros, los resultados futuros
del proyecto. En segundo lugar, la posibilidad de definir y
experimentar diferentes escenarios sin asumir coste o riesgo
alguno, es una de las principales cualidades de la
simulación de modelos en cualquier área.
También la gestión de proyectos software puede
verse favorecida por esta cualidad. Es posible, por tanto,
definir y experimentar diferentes mejoras de procesos, simular el
modelo, y analizar los resultados de manera que la mejora o
mejoras que se implementen de manera efectiva en el proyecto sean
aquellas que arrojaron los mejores resultados durante la
simulación. En tercer lugar, los modelos de
simulación también se pueden utilizar la
estimación de costes del proyecto; costes que pueden estar
relacionados con algún sector concreto del mismo, como por
ejemplo el coste de la calidad o el de las actividades de
revisión, o con el proyecto completo.

Las capacidades para facilitar las predicciones de la
evolución del proyecto, para establecer sus costes y para
evaluar el resultado de diferentes mejoras del proceso
constituyen tres de los factores principales para el progreso en
los niveles de madurez del modelo CMM.

2.2 Estructura del DIFSPI

La gestión de proyectos se compone de una serie
de actividades que se encuentran integradas en el sentido de que
una determinada acción desarrollada en un área
afectará muy posiblemente a otras áreas. Por
ejemplo, un retraso en el calendario afectará siempre al
coste del proyecto, pero podrá o no afectar a la
motivación del equipo o a la calidad del producto. Las
interacciones entre las distintas áreas de la
gestión de proyectos son tales que en muchas ocasiones el
rendimiento de alguna de ellas sólo puede conseguirse
sacrificando el rendimiento de otra. Un ejemplo claro de este
comportamiento podemos encontrarlo en la frecuente
práctica de reducir la calidad o los requisitos
implementados en una versión concreta del producto
software con el fin de cumplir las previsiones temporales o de
coste.

Los modelos dinámicos favorecen la
comprensión de esta naturaleza integrada de la
gestión de proyectos al describirla a través de sus
procesos, estructuras e interrelaciones principales.

En el marco que proponemos, la gestión de
proyectos se considera como un conjunto de procesos
dinámicos interrelacionados.

Los proyectos se componen de procesos. Cada proceso
está formado por una serie de actividades encaminadas
hacia la consecución de un objetivo [3]. Desde un punto de
vista general, podría decirse que los proyectos se
componen de procesos que pertenecen a una de las siguientes
categorías principales:

– Proceso de gestión de proyectos.
Esta categoría recoge a todos aquellos procesos
relacionados con la descripción, organización,
control y dirección del proyecto. – Proceso software o de
ingeniería. Todos los procesos relacionados con las
actividades propias de la especificación y
construcción del producto software estarían
recogidos en esta categoría.

Ambas categorías interaccionan durante el ciclo
de vida de un proyecto según se muestra en la figura 2. A
partir de una planificación inicial llevada a cabo por los
procesos de gestión, los procesos de ingeniería
comienzan a desarrollarse. A través de la
información del progreso de los procesos de
ingeniería será posible determinar las
modificaciones a la planificación necesarias para
satisfacer los objetivos del proyecto.

El DIFSPI propuesto sigue esta clasificación y se
estructura, por tanto, en torno a los procesos de gestión
y de ingeniería. En ambos niveles, la utilización
de modelos dinámicos para simular los procesos reales y
para la definición y construcción de bases de datos
históricas será la característica
predominante.

Proceso de ingeniería en el
DIFSPI

En este nivel, los modelos dinámicos permiten
simular el ciclo de vida del producto software. Los beneficios
que puede aportar utilizar la simulación en este nivel son
los siguientes:

– La construcción del modelo obliga
a mejorar el conocimiento que se tiene del proceso de desarrollo
de software. Al tener que establecer los límites y el
ámbito de aquellos comportamientos del sistema real que se
pretenden estudiar mediante simulación estamos obligados a
aumentar nuestro conocimiento. – Los parámetros requeridos
por el modelo y las tablas que gobiernan su comportamiento
temporal constituirán los elementos constituyentes del
programa de recogida de métricas del proceso de desarrollo
y la definición de la estructura de una base de datos
histórica. – La aplicación del programa de
métricas permitirá la realización de
inserciones en la base de datos histórica. – Los datos
históricos favorecen el proceso de validación y
calibración del modelo dinámico. – El modelo
dinámico, finalmente, simula los procesos de desarrollo
con el conocimiento, y la madurez, de los que dispone la
organización. – La utilización del modelo
dinámico permite el establecimiento de la línea
base del proyecto, la investigación de mejoras de procesos
y la construcción de una base de datos, alimentada por los
resultados de la simulación, que permita realizar
análisis de las diferentes mejoras de procesos.

Los modelos dinámicos utilizados en
este nivel deben respetar la visibilidad y el conocimiento de los
procesos de ingeniería que las organizaciones tienen en
cada uno de los niveles de madurez. Resulta obvio que la
complejidad del modelo dinámico que utilicen las
organizaciones de nivel CMM-1 no puede ser la misma que la
complejidad del modelo adecuado para los procesos de
ingeniería de una organización de, por ejemplo,
nivel CMM-3. Y esto es así, porque el conocimiento que de
los procesos tienen las organizaciones está restringido,
como ya hemos comentado, por su nivel de madurez.

Proceso de gestión en el
DIFSPI

Los procesos de gestión se
encuentran divididos en dos grandes categorías:

– Planificación. Recoge los procesos
destinados a establecer la planificación inicial y las
modificaciones necesarias según sea el progreso informado
del proyecto. En este apartado se integrarán las
técnicas tradicionales de estimación y
planificación junto con las técnicas de
simulación de modelos dinámicos. – Control.
Aquí se agrupan todos los procesos encargados de realizar
la monitorización y seguimiento del proyecto. La
decisión de acciones correctoras también
será responsabilidad del proceso de control por lo que
aquí cobrará una gran importancia la
simulación de mejoras del proceso.

2.2.1 Elaboración de los modelos
dinámicos

El enfoque seguido en la construcción de los
modelos dinámicos se basa en dos principios fundamentales.
Por un lado, el principio de extensibilidad de dichos modelos,
según el cual, partiendo de un modelo inicial
básico que recoge los comportamientos fundamentales de un
proyecto software se van añadiendo componentes
dinámicos que modelan las áreas claves de proceso
que integran el paso hacia el siguiente nivel de madurez. Estos
componentes pueden ser "habilitados" o "deshabilitados"
según sea el interés del director del proyecto o
del SEIG.

En segundo lugar, el principio de
agregación/descomposición de tareas en
función del nivel de abstracción que se requiera
para el modelo. Se utilizarán dos niveles de
agregación:

– Agregación horizontal, mediante la
cual, diferentes tareas secuenciales del proyecto se agrupan en
una única tarea con un único plazo. –
Agregación vertical, mediante la cual, diferentes tareas
individuales, pero paralelas e interrelacionadas se consideran
como una única tarea con, también, un único
plazo.

La definición del nivel apropiado de
agregación o de descomposición de las tareas
afecta, sobre todo, al modelado de las actividades de
ingeniería y depende, principalmente del nivel de madurez
de los procesos que se pretenden modelar y simular.

Para la definición del modelo inicial
básico se tiene especialmente en cuenta la
utilización de aquellos lazos de realimentación
comunes a los proyectos de desarrollo de software y que resultan
lo suficientemente genéricos a todos ellos, evitando
modelar aspectos concretos de organizaciones especificas que
limiten la flexibilidad del DIFSPI. Por otro lado, en la
instanciación de las funciones y parámetros
principales de este modelo inicial se utiliza información
procedente del análisis de bases de datos
históricas y que se encuentra disponible en la literatura
[4].

A partir de este modelo inicial básico y
utilizando la capacidad de replicación de ecuaciones
ofrecida por el entorno de simulación Vensim® se
desarrollan los modelos adecuados para simular organizaciones de
nivel de madurez superior. Así, por ejemplo, si el modelo
inicial se puede utilizar para simular proyectos de
organizaciones situadas en el progreso del nivel 1 al 2, el
modelo adecuado para las organizaciones con un nivel de madurez
superior hará uso de la replicación de la
estructura del modelo inicial para crear tantas subestructutras
como fases o actividades determine la estructura de
partición del proyecto (análisis, diseño,
codificación y pruebas, en nuestro caso). Según
este procedimiento, cada vez que se replique un modelo completo o
una parte del mismo, será necesario definir los nuevos
mecanismos (módulos dinámicos) de acoplamiento
entre las nuevas subestructuras creadas. Estos mecanismos
permitirán implementar de manera efectiva el principio de
agregación/descomposición anteriormente
comentado.

La replicación de estructuras también nos
permite la posibilidad de replicar los módulos asociados
con el modelado de los procesos de gestión del proyecto.
Esta replicación va a resultar especialmente útil
para las organizaciones de nivel de madurez superior, en las que
será posible establecer políticas de mejora de
procesos específicas para cada actividad concreta del
ciclo de vida del proyecto.

Como ya hemos indicado, el nivel de agregación o
de descomposición, en definitiva el nivel de
abstracción del modelo de simulación va a venir
determinado por el nivel de madurez que posea la
organización. Este nivel de madurez determina el grado de
visibilidad y de conocimiento que la organización tiene de
sus procesos. La complejidad de los modelos de simulación
estará, por tanto, en función de esta
visibilidad.

4 Utilización de la simulación en los
diferentes niveles de madurez

El modelo CMM proporciona un marco de trabajo
incremental excelente para ganar experiencia a través de
la simulación. De hecho, la simulación puede ser
utilizada en todos los niveles de CMM con diferentes grados de
sofisticación.

El desarrollo de un modelo de simulación puede
resultar una tarea relativamente fácil; no así
validarlo con datos reales. Las organizaciones que utilicen un
modelo dinámico de simulación deben poseer la
información suficiente que permita validar sus procesos
simulados. Por tanto, en función del nivel de madurez que
posea una organización, le corresponderá un modelo
dinámico más o menos complejo.

A continuación, se describe la aplicación
de los modelos dinámicos de simulación a cada uno
de los niveles del modelo CMM.

Nivel 1

En este nivel es del todo recomendable introducir la
idea del proceso de software como un entidad dinámica cuyo
comportamiento está gobernado por lazos de
realimentación. Resulta muy útil colocar a los
directores de proyectos en entornos de simulación que les
permitan llevar a cabo experimentos y practicar juegos de
simulación. De esta manera, se pretende que el director
tome contacto con los entornos de simulación y con la
potencialidad y ventajas del empleo de este tipo de
modelos.

Nivel 2

Conforme se progresa hacia el nivel 2, las
organizaciones pueden comenzar a diseñar modelos de sus
procesos y examinar algunas de las propiedades de sus
comportamientos. En concreto, se pueden desarrollar modelos de
gestión de proyectos muy generales (sin un alto nivel de
detalle) que permitan simular aspectos tales como la
planificación, el seguimiento y supervisión del
proyecto. En este nivel de madurez, sólo se
dispondrá de medidas muy generales (basadas en la
experiencia en la mayoría de las ocasiones) relativas a
los costes y al calendario. Las métricas del producto,
como por ejemplo la densidad de errores, no están
disponibles todavía. Por tanto, estos modelos de
simulación sólo serán aproximados en cuanto
al nivel de detalle al que se pueden construir y a la
precisión de los datos que reciben en su entrada. No
obstante, representan un comienzo importante para la
predicción cuantitativa.

Las entradas más comunes para los
modelos de simulación situados en el nivel 2
son:

– Dependencias de tareas. – Duración
de las tareas. – Ciclo de repetición de tareas. – Datos de
gestión de personal (contratación,
adaptación, etc.).

Las salidas pueden incluir datos
sobre:

– Calendario del proyecto. – Perfil de
evolución del presupuesto. – Perfil de evolución de
personal.

Las herramientas de simulación
actuales permiten la rápida construcción de modelos
muy sofisticados. Sin embargo hay que tener en cuenta que dadas
las limitaciones de los datos métricos disponibles en el
nivel 2, la validación de los modelos a este nivel es muy
difícil de alcanzar. Por tanto, en este nivel se pueden
utilizar los modelos para obtener avances cualitativos, pero su
capacidad de predicción cuantitativa debe estar
todavía cuestionada.

Nivel 3

Las organizaciones del nivel 3 aplican un
énfasis especial sobre la ingeniería del producto,
la definición formal de los procesos de ingeniería
y la instrumentación de estos procesos. Por tanto, la
gestión (que inicialmente trataba a las actividades de
ingeniería como cajas negras) posee ahora conocimiento
sobre el interior de estas actividades. Los datos recogidos de la
observación de los procesos de ingeniería pueden
servir de soporte para las actividades de simulación, para
comprender el comportamiento, estabilidad y sensibilidad de los
cambios. Ya que los procesos de ingeniería conducen muchos
de los procesos de gestión, la simulación precisa
del nivel de ingeniería resultará en una
precisión mejorada en el nivel de gestión. Por
ejemplo, las tasas de corrección de errores afectan al
tiempo de finalización de los módulos software y
esto, tiene un efecto directo sobre el calendario del
proyecto.

Las entradas más comunes a las
simulaciones del nivel 3 pueden incluir (además de las del
nivel 2) datos sobre:

– Cambios en los requisitos. – Defectos de
diseño. – Defectos de codificación. – Pruebas y
revisiones.

además de distribuciones estadísticas de
éstos. Las salidas pueden incluir datos sobre:

– Calidad del software. –
Información sobre el ciclo de vida.

El nivel 3 también otorga una gran importancia a
la definición, mantenimiento y reutilización de
procesos en una organización. Esto implica que las
organizaciones del nivel 3 deberían soportar una
librería de los procesos que pueden reutilizarse, con una
adaptación adecuada, en otras partes de la
organización. Manteniendo las definiciones de los procesos
como modelos de simulación, un usuario futuro de un
proceso existente puede evaluar las características de
evolución de los procesos dentro del contexto de un
proyecto para un nuevo usuario y puede adaptarlo de una manera
mucho más precisa que los procesos estáticos
tradicionales.

Finalmente, en el nivel 3 la formación recibe un
gran énfasis. En muchas industrias, la simulación
es un componente esencial de esta actividad. Sin embargo, la
industria del software no ha explotado aún esta
aplicación. Como herramienta de entrenamiento, la
simulación puede ayudar a mejorar el proceso de toma de
decisiones. Las áreas claves de proceso como el
seguimiento y supervisión, aseguramiento de la calidad e
ingeniería del producto software son candidatos perfectos
para el entrenamiento basado en simulación.

El énfasis de las prácticas de
ingeniería en el nivel 3, hace que sea muy importante
recoger métricas del producto. Estas métricas
están asociadas con parámetros como la
duración de las tareas, la estabilidad de los requisitos y
los defectos de diseño y codificación y
permitirán validar los modelos de simulación con un
alto grado de confidencialidad. Además, las
métricas de cada parámetro se deben recoger con el
detalle suficiente para permitir la generación de
distribuciones estadísticas. Las simulaciones
estocásticas que utilizan estas distribuciones
permitirán acceder a la incertidumbre de las variables
independientes como, por ejemplo, la productividad del equipo
técnico. Tener el conocimiento de la incertidumbre
asociada con el coste o calendario planificado inicialmente
sería de un valor inapreciable en la gestión de
riesgos y mejora del proceso.

Nivel 4

Los modelos de los niveles 3 y 4 no difieren
significativamente en su nivel de detalle o
instrumentación. Sin embargo, en el progreso hacia el
nivel 4, la validación de los procesos simulados gana en
rigor y refleja el nivel de confidencialidad ganado a
través de la experiencia. Si se realizan modificaciones a
los modelos del nivel 4 existe una alta probabilidad de que los
cambios de comportamiento que exhiba el modelo se produzcan
también en la realidad. Esto proporciona a la
dirección la confianza de que las predicciones resultantes
de la simulación son generalmente mejores que las que se
basan, en exclusiva, en el juicio humano. Los directores son
más capaces de asumir los riesgos de modificar sus
procesos o integrar nuevos elementos en los ya
existentes.

En el nivel 4, el objetivo es operar los procesos dentro
de límites de rendimiento cuantitativo. La
simulación es un medio para determinar cuáles deben
ser esos límites. En primer lugar se deben determinar los
límites de las variables dependientes (límites
principales de coste, plazo y calidad). Estos límites
actúan como restricciones de las variables independientes
tales como densidad de errores, recursos, etc. A través de
la simulación es posible determinar los límites
superiores e inferiores que estas variables dependientes no deben
exceder con el objeto de que el coste, la calidad y el plazo se
mantengan dentro de los límites aceptables.

En este nivel, la simulación también va a
permitir predecir (dentro de un intervalo de confianza) si el
proyecto va a cumplir con éxito los objetivos del
proyecto. Por otro lado, estas averiguaciones se pueden hacer en
cualquier momento del ciclo de vida, basta con inicializar el
modelo con una instantánea de los datos actuales del
proyecto real.

Nivel 5

A partir de las experiencias del nivel 4, se obtienen un
conjunto de métricas de calidad, modelos validados que
pueden utilizarse para seguir y dirigir (en tiempo real) el curso
del proceso. En el nivel 5 esta experiencia se utiliza para
realizar cambios más radicales en los procesos, es decir,
para cambiar los componentes principales de los mismos. En el
nivel 5, se prueban mejoras o nuevas maneras de construir el
software en un ambiente controlado. Insertar un nuevo componente
en un proceso posee un elemento de riesgo independientemente de
cuáles sean las técnicas de análisis. Pero
las ventajas ofrecidas por el uso de la simulación ayudan
a reducir el riesgo de manera significativa. Además, es
posible comparar la salida de la simulación del cambio en
un proceso, con la salida real de ese proceso sin
modificar.

Un factor muy importante en el nivel 5 es la capacidad
de responder rápidamente a la nueva tecnología, por
ejemplo, las herramientas CASE y las herramientas de flujo de
trabajo. La inserción de estas nuevas tecnologías
posee importantes efectos, entre los que destacan los factores de
riesgo humano, que la simulación no puede tener en cuenta
de manera completa, pero su utilización nos puede orientar
sobre sus efectos. Existe también una importante
conexión entre la simulación, el flujo de trabajo y
las métricas. Por un lado, la simulación puede
identificar dónde puede instrumentarse un proceso (es
decir, los puntos en los que los datos deben insertarse para
conducir la simulación). Por otro lado, el flujo de
trabajo nos ofrece la oportunidad de recoger métricas
automáticamente en una rutina, no intrusiva y de una
manera precisa. Por tanto, la simulación soporta el flujo
de trabajo apuntando al lugar donde éste debe ser
instrumentado, mientras que el flujo de trabajo proporciona los
datos que permiten validar la simulación.

En resumen, las organizaciones de nivel 5 poseen modelos
detallados y validados para sus procesos. Son capaces de realizar
cambios importantes en sus procesos, validarlos a través
de la simulación y poseen un alto nivel de confianza que,
cuando se lleva a la práctica hace que los procesos
respondan de la misma manera que lo hace la evolución
real. El énfasis sobre la inserción
tecnológica que se realiza en el nivel 5, puede verse
favorecido por la simulación que permite averiguar el
impacto de los cambios de herramientas sobre el proceso antes de
llevarlo realmente a la práctica." (Ver anexo
2).

El modelo CMM desarrollado para BNYCS, se bautizo con el
nombre "OPM3". Este afianza la clasificación
jerárquica nivelada a la madurez y minimizando la
posibilidad de un descenso en esta a través de un modelo
personalizado.

Este modelo personalizado de BNYCS, debió seguir
los siguientes parámetros para un posicionamiento
estratégico:

• 1 Alineación del modelo de
  madurez con el comité de OPM3 a PMI

• 2 Direccionamiento en la
  investigación de las normas de dirección del
  proyecto, prácticas metodológicas,
  etc.

• 1. Interacción entre los
  empleados de BNYCS y los consultores de
  Whittman-Venado

• 2. Estudio y adaptación al
  modelo de madurez OPM3, de las funciones ejercidas por los
  ejecutivos de BNYCS.

• 3. Rastreo de los consultores
  sobre las fases individuales de los funcionarios de BNYCS,y
  con ello determinar el nivel de madurez en cada
  proceso.

10.Identificar la importancia que tiene un requerimiento
en términos de implementación. A esta
característica se le conoce como prioridad y debe ser
usada para establecer la secuencia en que ocurrirán las
actividades de diseño y prueba de cada
requisito.

11.Desarrollo de una matriz, con los cinco niveles de
madurez que muestran la cuenta compuesta para una
organización

12.Tener un ROI positivo, que necesita de beneficios
mayores que el costo de crear y usar el modelo de Madurez
OPM3

Además, el identificar debilidades y
vacíos en BNYC, facilitaron que la implementación
de una oficina de proyectos se tradujera en un ROI
positivo.

La dirección de la organización determina
que parte del publico puede intervenir en la valoración y
cuales son las áreas de la compañía que
están involucradas en la dirección del proyecto y
que serán valoradas.

El paso siguiente en el modelo de madurez, es generar un
proceso continuo de valoración, el análisis, planes
de mejora. En fin el modelo de madurez OPM3 de BNYCS, se
convirtió en una herramienta para la dirección
continuada de proyectos.

El CEO debe poseer claridad sobre el monitoreo a
realizar una vez implementado un modelo de madurez, y que las
causas que pueden cambiar los requerimientos son:

"Porque al analizar el problema, no se hacen las
preguntas correctas a las personas correctas.

• "Porque cambió el problema que
  se estaba resolviendo.

• Porque los usuarios cambiaron su forma
  de pensar o sus percepciones.

• Porque cambió el ambiente de
  negocios.

• Porque cambió el mercado en el
  cual se desenvuelve el negocio."10

Finalmente," Curtis y Paulk en 1993 realizaron un
comparativo entre los procesos maduros e inmaduros, con el fin de
comparar los extremos y crear un marco de referencia, y es el
siguiente:

Dados estos factores parecen obvios los
beneficios adquiridos al paso de los niveles y hace aun
más importante para las organizaciones el interés
en cambiar paulatinamente a estos resultados. Existen varias
maneras para evaluar el impacto del CMM como la matriz de
alineamiento estratégico en la cual es posible ponderar
actividades y costos evaluando su importancia en el proceso. Con
el fin de identificar los puntos de mayor atención en los
proyectos y así dirigir los esfuerzos de una manera
más eficiente. Otra manera de evaluar un proyecto es
mediante sus habilidades y beneficios en cada nivel del CMM, y de
esta manera encontrar fácilmente las evoluciones en
distintas características de nuestra calidad y
desempeño."11

CONCLUSIÓN

Un tópico especial en la
administración de proyectos bajo la metodología
PMI, es el desarrollo de software orientado a medir y certificar
la calidad, tanto del sistema a desarrollar, como el proceso de
desarrollo en si. En fin el modelo de madurez CMM personalizado
para la compañía BNYCS y denominado OPM3, se
convirtió en una herramienta para la dirección
continuada de proyectos. Cumpliendo así con los objetivos
fundamentales del modelo CMM: establecer un indicador de calidad
y una mejora continua de la organización.

1 Cleland, David I. y Ireland, Lewis R. Manual
Portátil del Administrador de Proyectos. Primera
Edición. Editorial Mc Graw Hill. México 2001,
seccion 10.7

2 Ver anexo 1

3 Basado en "Programa Especial de Ciencia y
Tecnología: 2001-2006" (Versión Preliminar).
CONACYT, Agosto 2001.

4 Basado en "PECyT: 2001-2006". Op.,
Cit.

5 La innovación
tecnológica consiste en un cambio positivo en el proceso
de producción,

producto, administración o
servicio que se traduce en una mayor eficiencia,
mejor

6 Respectivamente: Presidente y
Director General Infosys Technology Ltd. India. Y Jefe del
Instituto de Ciencias de la Computación Instituto
Tecnológico de la India.7 Presidente para las
Américas Enterprise Ireland.

8 "Process Maturity Profile Of The Software Community
2000 Year End Update". -SEMA.3.01. Software Engineering
Institute: Carnegie Mellon University. March 2001.

9 Op., Cit.

10 Cleland, David I. y Ireland, Lewis R. Manual
Portátil del Administrador de Proyectos. Primera
Edición. Editorial Mc Graw Hill. México 2001,
seccion 10.7

11 Ver anexo 1

Autor:

Carlos Alberto Palacio
Londoño

Economista, M. Sc. Administración de
Proyectos , UCI de Costa Rica Institución Universitaria
Colegio Mayor de Antioquia Unidad de Emprendimiento